Electronic records can be modified relatively easily and without leaving much of a trace. As organizations increasingly rely on electronic records, it is important to protect these records from both accidental and intentional modification including deletion by, for example, storing the records in some forms of storage that disallows update and/or delete. Such storage is generally referred to as WORM storage.
In particular, one approach is to write the electronic records to a storage system that protects data from modification as data is written to it. This type of commit-on-the-fly approach is, however, overly restrictive and cumbersome for protecting whole data objects from modification.
Another approach is to allow normal update operations against a data object until an explicit signal is received to commit the data object to be immutable. Such an approach, however, requires applications to be modified to issue a specific commit signal. Without support from the applications, a user has to explicitly issue the commit signal or write scripts to issue the commit signal, both of which tend to be laborious and error-prone.
The storage system can automatically commit data objects that match a certain criteria to be immutable. However, as with other techniques that do not rely on application support, determining when a data object is ready to be committed is difficult, especially when the record is received through a network file protocol that may not have an explicit “object close” API (application programming interface).
One technique is to commit a data object to be immutable after the data object has not been accessed for a predetermined period of time. The number of data objects that must be tracked for this technique could, however, be very large. Another technique is to periodically scan the data objects to commit those objects that have not been updated recently, but this becomes increasingly inefficient as the number of objects in the system grows.